Funnel Basics
FunnelFlux has some key differences when compared to most performance marketing-focused tracking platforms such as Voluum, Redtrack, Binom etc.
The most distinct being the existence of a "funnel" entity, which changes the way we approach "campaigns", link generation and traffic source segregation.
Typically, one might expect to do the following in another tracker:
- Create some sort of flow/path, which defines landers followed by offers. Incidentally, this means the tracker may often return a lander to a new visitor and predetermine what page they may go to next if they click through -- FunnelFlux has no such predetermination.
- Create a campaign. Here you will select a traffic source, often a country, and a flow/path that this "campaign" will direct to.
- You save and the campaign gets a unique URL, often a hashed code for that campaign ID + additional parameters for the traffic source
- If you want to launch a new campaign on a traffic source, whether it be for a new country, carrier splitting, angles, etc., you create a new "campaign" in the tracker with its own unique link.
- Likewise, if you want to launch the same campaign on a new traffic source, you need to make a new "campaign" in the tracker --> get a new link --> use that.
From our perspective, this is a tedious process that creates a lot of unique links needlessly, with a lot of micro-management of individual "campaigns".
Here's where FunnelFlux is different:
- Users create a "funnel", which essentially a logic diagram, a flow chart, describing the decision making process of the tracker and the nodes users will navigate through. Those nodes may be server-side and perform functions (such as a condition or rotator node), or could be page nodes that return a URL to the user to load.
Here is an example funnel:
- When launching a campaign on a traffic source, users will click any node in the funnel (often the default traffic node), select their source, and retrieve a generated link. This link does not need to be saved. It is a URL construct created in real-time.
- Values like campaign name or ID are expected to be passed dynamically under the "campaign" URL parameter from the traffic source config, such that the IDs/names are passed from the traffic source directly. In the future we intend to add integrations that will sync with traffic sources to provide ID > name mapping, such that only ID is passed. For now, users may pass name or ID depending on preference.
- Whenever the user wants to launch a new campaign on any traffic source, they repeat this process. A funnel can receive traffic from unlimited traffic sources, provided the user expects them to go through the same funnel journey (if not, they could use condition nodes, or make a new funnel to separate the journey configuration).
See how this differs?
The funnel entity is a thus logic map which can accept any traffic and routes that traffic accordingly.
Funnel Structure
Funnels are composed of two key elements
- Nodes
- Connections
For connections, those may be:
- Simple connections extending from rotator nodes, for which they have a % weight
- Route connections extending from a condition node, which are the results a condition node returns
- Action connections from a page group, which are what are executed when a user clicks and action URL on a page
Each node has a globally unique ID within a funnel. These IDs are generated at the time of node-creation and can be seen by clicking a node --> top right corner.
Nodes
Users can create nodes by right clicking > add node type, or by opening the node palette on the left-hand side, then dragging and dropping.
The context menu only creates local nodes, global nodes are available in the palette only.
In the palette, users can search through their account's resources to find pages and other items to add.
Connections
Connections are made between nodes by dragging and dropping from origination node to destination node.
These connections are part of the funnel schema (which is a JSON object) and specify the ID of the originating/destination node, as well as any other important parameters.
For rotators, these connections have a rotation weight expressed in percent.
For conditions, these connections have a route label. There must be a 1:1 match of condition connections to routes defined in the node.
For page groups (which can contain one or many pages), the outgoing connections represent user actions and each have one or more numbers defined.
Local vs Global Nodes
Some nodes may be "global" and have a (G) label on them. In particular, page group and condition nodes.
These are nodes that exist within a funnel, like any other, but their config is mapped to an external resource.
In this way a "global condition" could be reused in many funnels (such as for a routine mobile vs desktop splitting) and the condition config managed outside of the funnel on the conditions page.
Changes to that global resource then impact all funnels in real-time.
Likewise, users can create global page groups and add these to a funnel. This creates a local node ID, which has its config linked to an external page group ID. If it were a local node, the config is stored in the funnel schema itself.
Action Connections and Links
Outgoing connections from any page-type node are actions and have a numerical label.
These links are of the format:
https://USER_DOMAIN/action/number
e.g.
https://tracking.funnelflux.com/action/1
The action links are universal and available in multiple parts of the UI, including by right clicking on the connection > get action link:
A page node can have up to 255 outgoing actions. In the visual builder, a single connection can represent one or many actions (for convenience and to reduce clutter).
This can be accomplished by right-clicking > modify action:
When a visitor arrives on a page node then is redirected to an action URL, by a click or JavaScript, the tracker will take the specified action number and execute (i.e. traverse) the corresponding action connection, traveling to whatever node this connection goes to.
Additionally, users may toggle on "Default redirect parameters" to get an action link with fallback parameters in it, like so:
This link structure is:
https://USER_DOMAIN/FUNNEL_ID/ORIGINATING_NODE_ID/action/number
These give a default action for the link to take in the event that the link is loaded from an unknown source.
It's important to note that these default parameters are NOT overrides. They will only be used in a circumstance where the user has no active, known session and thus no known current node.
In all other circumstances, the tracker will simply execute action X from the node it believes the user is on (whether such a connection exists or not).
In situations where our JavaScript tracking is present on both pages, users may also link directly from page A in a funnel to page B. If these pages are connected by an action, our edge will retrospectively add a click event. This is useful for tracking sites where links cannot be replaced with tracker action links and a single flow is required (i.e. pages are directly linking to each other with no need for control over routing, split-testing etc.).
Funnel Entrance Links
Entrance links are those used at traffic sources to send a user to a funnel. They should only be loaded by a user when they are to ENTER a funnel. After that, internal funnel navigation should be accomplished by action links, unless the visitor is entering a separate funnel or coming from a new traffic source.
Redirect Links
When a user wants to generate a URL for tracking, they can click any node in the funnel > redirect links > choose their config and get the generated URL:
This URL is of the structure:
https://USER_DOMAIN/fts/FUNNEL_ID-TRAFFIC_SOURCE_ID/OPTIONAL_NODE_ID + TRAFFIC_SOURCE_URL_PARAMS
Node ID an is only injected when a node other than the default traffic node is used.
The URL parameters appended to the end come from the traffic source config at the time of selecting that source from the dropdown.
These links use the user's custom domain and direct traffic to our /fts/ handler, which then redirects accordingly based on the URL parameters.
On redirect, our edge checks the hostname against the funnel ID. If the owner of the funnel is not the domain owner, the request will fail.
If the funnel ID owner does not have the custom domain added in their account, it will also likely fail.
Direct Links
Direct links can be used in tandem with our JavaScript tracking and can only be generated for pages (obviously, since a page must be served in order for JS to execute).
When generating direct links, users must pick the specific page within the page group if more than one exists.
The direct link URLs are of the structure:
PAGE_URL + f=FUNNEL_ID&ts=TRAFFIC_SOURCE_ID&n=NODE_ID + TRAFFIC_SOURCE_URL_PARAMS
These pass the same URL data as our redirect links but in the query string only.
On loading the page, our JavaScript will execute and from the URL, detect the funnel/traffic source and node ID, then subsequently track the visit and push all additional parameters for the edge to digest (it will only save the ones that exist in the traffic source config to the database, so extra parameters manually added would be ignored)
Our JavaScript is discussed in another article, and it has important on-page functions besides the initial view tracking.
Additional Settings and Config
Funnel Additional Settings
From the buttons in the top-left you can access a funnel's settings. Here there is a default cost per entrance -- this will inherit to the link generator form in this funnel, provided no higher priority value exists (check the tooltip).
Under advanced settings you can also take several actions:
- Override the IP anonymisation settings for visitors entering the funnel
- Declare linked funnels. These are funnels that users from this funnel may later jump to, where you want revenue from the visitor to indirectly attribute back to this funnel. This is discussed further in another document
- Incoming cost overrides. This is the highest-level cost override in our system and it will apply a per-source cost value to incoming users regardless of any cost parameter in the URL query string.
Page Node Additional Settings
Additional settings are available on page nodes:
- Receive Accumulated URL Parameters. This will append all known URL parameters for the user to the page URL. This includes parameters from the original entrance URL and any manually injected into action links. All such URL parameters enter what is known as our "URL buffer" in our visitor session object (which exists in an edge cache). Enabling this option causes the entirety of the buffer to be appended. Use with caution as its often a lot of URL data for a page to have.
- Append Extra URL Parameters. Here you can manually append custom strings, which includes our internal tokens
- Override redirect mode. Overrides the redirect mode for navigating TO this page, in the event of a redirect/action link sending a user TO this page. This does not impact redirect modes on pages a user would go to when clicking an action link ON this page.